home *** CD-ROM | disk | FTP | other *** search
/ MACD 5 / MACD 5.bin / workbench / wb / czesc_2 / memmometer / mm.doc < prev    next >
Text File  |  1992-11-06  |  25KB  |  407 lines
  1. /*
  2.  *   Information for MM Version 2.40, 11-Oct-1992
  3.  *
  4.  *   MemMometer - A program hacked from Tom Rokicki's WFrags more or less...
  5.  *   (in fact, a heck of a lot) in the style of Peter Da Silva's "Gauge."
  6.  *   The program opens a narrow window with the same dimensions as the disk
  7.  *   capacity gadget found in the top-level workbench window for an Amiga
  8.  *   DOS v1.3 floppy volume.  The sizing gadget is like the one in Gauge;
  9.  *   to resize the window, just click the left mouse button over the "E".
  10.  *   The "F" is the program title in this rather short manifestation of
  11.  *   an Amiga Intuition window drag bar.
  12.  *
  13.  *   My bin copy of Gauge broke when I put a Michigan Insider in my A1000.
  14.  *   I did not have source for the Gauge program, so I conjured this one.
  15.  *   To my chagrin, MM 1.0 broke when I got a 2000 (more on that shortly),
  16.  *   the Amiga 3000 blew away the previous version of this program, too,
  17.  *   of course.  But that's the way it is with hardware-oriented software
  18.  *   hacks! :-|  Changes with this version include an ARexx Port to allow
  19.  *   greater flexibility in setting the menu items than is provided by the
  20.  *   menu items alone, and rearrangement of the menus for A3000 and A4000
  21.  *   memory spaces, plus code to keep the menu driven choices from kicking
  22.  *   the Enforcer.  Please note that Amiga DOS allocates A3000 memory space
  23.  *   in heap fashion (autoconfiguring memory in successively lower addresses
  24.  *   starting from the top, while utilizing it within each zone in the usual
  25.  *   fashion from the bottom up).  The following table describes how to set
  26.  *   MM for various Amiga 3000 and 4000 motherboard memory configurations:
  27.  *
  28.  *                          Fast Ram Size    Base Address
  29.  *                              1 Meg           7f00000
  30.  *                              2 Meg           7e00000
  31.  *                              3 Meg           7d00000
  32.  *                              4 Meg           7c00000
  33.  *                              6 Meg           7a00000
  34.  *                              8 Meg           7800000
  35.  *                             10 Meg           7600000
  36.  *                             12 Meg           7400000
  37.  *                             14 Meg           7200000
  38.  *                             16 Meg           7000000
  39.  *   
  40.  *   MemMometer may be started from an icon, a CLI, or the Run command
  41.  *   from a CLI.  MM uses dynamic allocation for its display data, and
  42.  *   does its own resource tracking.  MM will surrender any resources
  43.  *   which it has successfully obtained from allocation requests if,
  44.  *   while MM is running, requested resources are denied.  This type
  45.  *   of fault (exit code 20) proceeds silently, and without any notice.
  46.  *
  47.  *   Now for a run through MemMometer's menu mechanics.  MemMometer opens
  48.  *   with a non-interlaced-screen-height narrow window at the left side of
  49.  *   the Workbench screen.  The window width is the same as the width of the
  50.  *   capacity gauge which Workbench used to render at the left side of the
  51.  *   v1.3 top level window for a floppy volume.  As with Peter Da Silva's
  52.  *   original gauge program, the MemMometer has an E at the bottom of the
  53.  *   window, and an F at the top.
  54.  *
  55.  *   The E and the F are respectively, the window sizing gadget, and the
  56.  *   window titlebar.  While MemMometer can and does automatically arrange
  57.  *   the window to suit the memory configuration, it depends on the user to
  58.  *   select appropriate memory size and address values via the menus.  The
  59.  *   menu style is the usual Amiga Intuition menu set; selection is achieved
  60.  *   by clicking the left mouse button while the mouse pointer is anywhere
  61.  *   within the program's window boundary, and then activating the menu bar
  62.  *   by holding down the right mouse button and sliding the mouse pointer
  63.  *   along the Workbench screen title bar at the top of the Workbench screen.
  64.  *
  65.  *   At the left side of the Workbench screen title is the Project Menu.  The
  66.  *   Project Menu has three options.  The first option is "Front", which is a
  67.  *   window-to-front command for the event that the MM window was partially
  68.  *   buried by the opening of new windows after MM was invoked.   If the
  69.  *   right mouse button is released while the mouse pointer is directly over
  70.  *   the Front menu item, the MM window will oblige by popping forward to an
  71.  *   unobstructed view.  The second menu option is the "Back" item, which
  72.  *   will move the MM window back behind any other windows that have been
  73.  *   opened on the Workbench screen (with exception of a backdrop window).
  74.  *   The third Project menu option is the "Quit" option, which directs MM to
  75.  *   close its window and release the AmigaDOS resources it has allocated.
  76.  *   The normal return code is zero.
  77.  *
  78.  *   The second Intuition menu is the Setup menu.  There are two Setup menu
  79.  *   items.  The first item is the "Mode" item.  MM has two modes, and they
  80.  *   are selected by sliding the mouse pointer straight down from the screen
  81.  *   title bar over the Mode item , and then moving the pointer to the right
  82.  *   as the mode submenu is activated.  The activated submenu provides two
  83.  *   choices, "Frags" and "Warps".  Frags are rather much the same as they
  84.  *   were in Da Silva's gauge program.  "Frags" is the default menu selection
  85.  *   with which MM is first initialized.  The Frags display is described in
  86.  *   the following table:
  87.  *   
  88.  *               2-Color Workbench    4-Color Workbench    8-Color Workbench
  89.  *  Unallocated      Dark Gray            Light Gray              Light Gray
  90.  *  Allocated          Black             Medium Blue                White
  91.  *  Fragmented       Dark Gray            Dark Gray               Dark Gray
  92.  *
  93.  *   Unallocated memory is free memory available to programs.  The programs
  94.  *   may obtain this memory from AmigaDOS through allocation requests.  The
  95.  *   Allocated memory is memory assigned to programs running under AmigaDOS.
  96.  *   Fragmented memory consists of interleaved small memhunks, some of which
  97.  *   are assigned to programs and some of which are in the free memory pool.
  98.  *   The smallest fragments are 8 bytes, and the largest memhunks may be more
  99.  *   than a megabyte.  The fragmented class is assigned when, in making the
  100.  *   MM window display, a single horizontal pixel line was found to represent
  101.  *   both allocated and unallocated memhunks.  For this reason, for a full
  102.  *   window height MemMometer, the resolution of the fragmentation is shown
  103.  *   in more detail on Amiga Workbench screens with the largest vertical
  104.  *   pixel count.
  105.  *
  106.  *   The second mode item selection is the "Warps" mode.  While the Frags
  107.  *   mode is usually utilized as a low-priority background indicator, the
  108.  *   Warps mode is usually utilized at a somewhat higher priority for the
  109.  *   purpose of tracking bugs and system irregularities.  In this context,
  110.  *   I define warps as a form of discretized sample-to-sample differencing
  111.  *   function for some arbitrary segment of memory.  Warps are determined by
  112.  *   dividing the selected address space evenly among the MemMometer display
  113.  *   pixels, computing an assignment checkfunction for each pixel line of the
  114.  *   display on the associated assigned memory space at some sample time, and
  115.  *   then, while retaining the previous pixel-by-pixel record, repeating the
  116.  *   same evaluation the second sample time and comparing the sequentially
  117.  *   determined checksums. A "checksum" is computed by means of a sequential
  118.  *   bit-wise eXclusive OR assignment.  This type of checksum can readily
  119.  *   detect zeroed or changed values.  In the table below, logical FALSE is
  120.  *   zero, logical TRUE is taken as 0x ffffffffffffffff and VALUE is then
  121.  *   anything else. Colors indicate the type of change.  Colors for the most
  122.  *   part follow the v2.0 standard CBM workbench color set:
  123.  *   
  124.  *                    Pen #   Color           Pen #   Color
  125.  *                      0     Gray              4     Blue
  126.  *                      1     Black             5     Magenta
  127.  *                      2     White             6     Cyan
  128.  *                      3     Med Blue          7     White
  129.  *
  130.  *   As this color table has two white values, some displayed information
  131.  *   will not be visible.  This problem can be overcome by setting Pen # 2
  132.  *   to a gray pen with RGB 13,13,13.  For the v2.0 workbench, the standard
  133.  *   colors are rather much too drab to allow MemMometer to be used as a
  134.  *   diagnostic tool, but one can readily choose a more useful palette such
  135.  *   as the Day8Color.pre or the Night8Color.pre file included in the MM2.40
  136.  *   distribution.  The Day and Night presets are similar, except the day
  137.  *   palette uses brighter gray colors rather than the darker blues used in
  138.  *   the night palette.  The night palatte has the least flicker for use of
  139.  *   interlaced displays.  For the Night presets, the pen colors are:
  140.  *
  141.  *                    Pen #   Color           Pen #   Color
  142.  *                      0     Medium Blue       4     Green
  143.  *                      1     Dark Blue         5     Cyan
  144.  *                      2     Light Blue        6     Yellow
  145.  *                      3     Red               7     Orange
  146.  *
  147.  *   These colors are used to map the changes in memory content from sample
  148.  *   to sample as programs multitask together:
  149.  *
  150.  *   Condition        2-Color Workbench  4-Color Workbench  8-Color Workbench
  151.  *
  152.  *   VALUE ===> VALUE     Medium Blue        Medium Blue        Medium Blue
  153.  *   VALUE =/=> VALUE     Dark Blue          Red                Red
  154.  *   FALSE ===> FALSE     Medium Blue        Light Blue         Light Blue
  155.  *   FALSE ---> VALUE     Medium Blue        Red                Orange
  156.  *   VALUE ---> FALSE     Medium Blue        Dark Blue          Cyan
  157.  *   TRUE  ---> FALSE     Medium Blue        Light Blue         Yellow
  158.  *   TRUE  ---> VALUE     Medium Blue        Light Blue         Yellow
  159.  *   TRUE  ===> TRUE      Medium Blue        Medium Blue        Green
  160.  *   FALSE ---> TRUE      Medium Blue        Medium Blue        Green
  161.  *   VALUE ---> TRUE      Medium Blue        Medium Blue        Green
  162.  *
  163.  *   The second Setup menu item is a Frequency selection submenu.  While the
  164.  *   selected value does set a minimum frequency with which the memory state
  165.  *   will be examined, it's done by introducing a delay between measurements.
  166.  *   The introduced delay will be equal in seconds to the value selected in
  167.  *   the submenu.  The delay is accomplished by the AmigaDOS timer.device
  168.  *   using the VBLANK mode.  Delay intervals of 1, 2, 5, and 10 seconds are
  169.  *   available from the menu.
  170.  *
  171.  *   The third Intuition menu is a Priority menu.  This menu applies only to
  172.  *   the MemMometer program and its associated CLI process.  Initially it is
  173.  *   at priority 0 with the expectation that the user will set it lower once
  174.  *   the program is running, in order to give more time to the other active
  175.  *   processes the user will be running.  A value of -50 is recommended.  In
  176.  *   the event the Priority of MM is changed via the menu, the CLI inherits
  177.  *   MemMometer's new priority and retains that priority even after MM quits.
  178.  *   Thus, with extreme priority settings, it may be better to "Run MM" to
  179.  *   keep from passing the extreme priority to subsequent processes spawned
  180.  *   from the CLI that was used to invoke MemMometer.  Also, go easy with the
  181.  *   positive priorities; remember that with AmigaDOS version 2.0 the DOS
  182.  *   input.device runs priority 20, the SCSI bus handler is 12, SCSI.device
  183.  *   is 11,  FileSystem is priority 10, and the CON: and trackdisk.device
  184.  *   are priority 5 usually.  Note that the first three MemMometer menu
  185.  *   items are used to increment or decrement a priority selected in the
  186.  *   lower part of the menu.  Selection of the "NORM" menu item removes any
  187.  *   increment or decrement previously set while at any given level.
  188.  *
  189.  *   The remaining Intuition menu selections are provided so that the range
  190.  *   and base address of the memory examined may be adjusted for the user's
  191.  *   Amiga memory configuration.  Note that for chip mem, at least, the base
  192.  *   address must always be set to the correct base address for the given
  193.  *   memory configuration in order for the Frags option to work properly,
  194.  *   but that the range may be adjusted to give a better resolution for the
  195.  *   first segments around the base address, if desired.  Menus are provided
  196.  *   for Chip memory, the old Slow-Fast (C00000/Ranger) memory, and Fast
  197.  *   memory.  While I have had no difficulty as a result of selecting a
  198.  *   range of memory that involved a non-existent seqment for Chip or Fast
  199.  *   memory in either Frags or Warps mode on an A1000, when I selected some
  200.  *   non-existent SFMemory on my Fat Agnus Amiga 2000 in Warps mode, it 
  201.  *   caused a total system-wide red Guru 4 (illegal instruction exception).
  202.  *
  203.  *   After that, I decided to post a requester to notify the user tersely
  204.  *   that a crash is _possible_ with incorrectly specified menu selections
  205.  *   the in warps mode.  Since it is possible, for example, to roll over
  206.  *   on 24-bit addresses via large memory size menu selections, one can
  207.  *   access forbidden zones through inappropriate settings of the Fast Mem
  208.  *   menus as well.  Thus MM also calls the requester if the Fast Mem size
  209.  *   menu is changed. The requester displays the message:
  210.  *
  211.  *                        WARNING! CRASH POSSIBLE
  212.  *                      MENU MEMORY SELECTIONS MUST
  213.  *                       REFERENCE EXISTING MEMORY
  214.  *
  215.  *                   Risk It                  Retreat
  216.  *
  217.  *   You don't have to worry about a crash if you really have an amount of
  218.  *   SF or Fast memory equal or greater than the amount you specified and
  219.  *   the base address is within what you specified (the default base address
  220.  *   for SF Mem is C00000 and 200000 for A2000 Fast Mem).  Too bad I had to
  221.  *   do this, but it is a matter the hardware regards seriously, as some
  222.  *   registers do things when they are read, never mind what they do when
  223.  *   they are written!  Of course, the program could be re-written to use
  224.  *   the autoconfig mem list to identify all valid segments of the memory
  225.  *   but then that would lessen its value as a snoop tool for situations
  226.  *   involving poorly behaved autoconfiguration hardware.  In this version,
  227.  *   though, requests for WARPS mode on chip memory with the base set to 0K
  228.  *   will result in a silently applied 1K offset in order to avoid Enforcer
  229.  *   hits.  So now the problem will remain only with Mungwall, if it happens
  230.  *   to be set to be sensitive to reads on unallocated memory.
  231.  *
  232.  *   So, here you see the two options.  The left button says - Risk It -.
  233.  *   That's a comfortable gamble if you know your Fast memory configuration.
  234.  *   Pre Fat-Agnus Amiga 2000 machines have 512K of Slow-Fast memory.  The
  235.  *   Newer 2000s have no C00000 Slow Fast memory, and the A3000 only has the
  236.  *   200000 ZorroII 16-bit Fast Memory if you added a Mem card - so beware
  237.  *   of this and try the other settings when you have nothing else going on,
  238.  *   until you gain a knowledge of what is safe.  The - Retreat - option sets
  239.  *   the SF or Fast Memory Size selected internal to the MemMometer program
  240.  *   to zero and clears the display.  (It does leave the menu items checked,
  241.  *   though, so you will have to remember to re-select suitable menu values
  242.  *   in order to get the display to show something in each existing memory
  243.  *   type.  For Chip and Fast memory this will simply entail going back into
  244.  *   the menu and again selecting whatever was previously checked.  The SF
  245.  *   memory size should be set either to appropriate values or to "NONE".)
  246.  *   
  247.  *   Note that in the display there may at any time be anywhere from one
  248.  *   to three MemMometers - for Chip (left-hand column), another for the
  249.  *   Slow Fast mem (center column) and yet another for Fast mem (right-hand
  250.  *   column).  These MemMometers can be turned on or off as desired by
  251.  *   selecting "NONE" or the various items in the Size menus.
  252.  *
  253.  *   With Version 2.40, ARexx is available via Tom Rokicki's MinRexx program
  254.  *   as a compling option.  It has been included in the V2.40 compiled code.
  255.  *   by invoking a rexx shell script via the "rx" command, the user can set
  256.  *   the menus to any value allowed within the MemMometer program's coded-in
  257.  *   ranges.  Note that the "Enforcer" address avoidance code built in with
  258.  *   this version for the menus is not applied to address and size values
  259.  *   invoked from ARexx scripts.  It is thus up to the script writer to be
  260.  *   sure that chip mem addresses below 1K are what the user wants to see.
  261.  *   Any so-invoked address below 1K will otherwise no doubt get a response
  262.  *   from the Enforcer program.  Sample ARexx scripts have been included in
  263.  *   the V2.40 distribution for each menu item.  Note: the first instance of
  264.  *   a mm executable invoked has the ARexx address "mm1", the second will be
  265.  *   "mm2", etc.  Up to four instances are allowed by the code in V2.40 -
  266.  *   You'd have to be some sort of prevert to want to run more than four
  267.  *   copies of this program in any Amiga, and you may have to be downright
  268.  *   looney to want to run even one copy for any longer than it took to find
  269.  *   out what was wrong with the hardware or software under test.  But you
  270.  *   can do it if you write the scripts to drive it.  I am grateful for, and
  271.  *   do wish to acknowledge the assistance via Usenet of Vince Herried and
  272.  *   Dan Barrett, two programmers who sent me email advice on how to get
  273.  *   minrexx going in general, and how to handle multiple invocations of the
  274.  *   program, in particular.  Without their help, revision to V2.40 would
  275.  *   have been longer in debug and test by probably quite some time.  And of
  276.  *   course, without Tom Rokicki's MinnRexx program (included in the codes)
  277.  *   it would have been impossible for one of my experience and intellect
  278.  *   to do this sort of thing at all (but you could tell that from looking
  279.  *   at my code, right?).  But I can say that my efforts in coding the
  280.  *   MemMometer program have survived three versions of AmigaDOS upgrades
  281.  *   without any major blow-up from that (the hardware already having been
  282.  *   forgiven).  Though it may be that this is more to the credit of the
  283.  *   Amiga operating system software designers than it is to any effort on
  284.  *   my part.
  285.  *
  286.  *   Parts of several freely distributable  programs have been used to make
  287.  *   MemMometer.  Menus, for instance, are done in the style VT100 (Wecker,
  288.  *   et al).  As with the VT100 program, MemMometer has preset variables.
  289.  *   As mentioned, the program now has an AREXX interface with which to
  290.  *   automatically set the variables.  I actually did get the code written
  291.  *   for that this century!
  292.  *
  293.  *   MemMometer uses forbid() and permit() when it examines the mem list in
  294.  *   Frags mode.  I suppose it is possible with large amounts of memory to
  295.  *   scan, that some gross treachery can happen while the list is locked.
  296.  *   However, neither my 6 meg Amiga 2500 nor my 4 meg Amiga 3000 seem to
  297.  *   have any problem with it.  It takes a while after startup to settle
  298.  *   and display the large byte counts associated with Fast mem, so try to
  299.  *   be patient...  MemMometer is most useful for finding out why large
  300.  *   programs won't load.  It's also useful in development for seeing the
  301.  *   impact your application is having on memory fragmentation, or how
  302.  *   various programs (and viruses, for that matter) are allocating memory.
  303.  *
  304.  *   The Warps mode displays any change it sees in memory from one sample
  305.  *   to the next; BUT this mode only works sensibly when JUST ONE memory size
  306.  *   selection is active (set others to "NONE").  The memory space is scanned
  307.  *   asynchronously, so it can have sample alias difficulties.  However, the
  308.  *   Warps mode does not use forbid(), permit(), enable(), disable(), or any
  309.  *   other constrictive system call.  It just does a lot of read-only memory
  310.  *   cycles and writes the result in its own dynamically allocated memory
  311.  *   space.
  312.  *
  313.  *   To run MemMometer, simply type
  314.  *
  315.  *      run MM
  316.  *
  317.  *      or  click on the icon.
  318.  *
  319.  *   Then open the menu item selections and set them for your configuration.
  320.  *   Frags mode, and 512K of CHIP @0 is the default these days, what with
  321.  *   hugh variety of configurations routinely encountered.  The modes are
  322.  *   are color coded into the "F" and "E" indicators in accordance with the
  323.  *   AmigaDOS 2.0 color table:
  324.  *
  325.  *   Mode       Indicator       2 color WB      4 Color WB      8 Color WB
  326.  *
  327.  *   Frags          E           Medium Blue     Light Blue      Medium Blue
  328.  *   Warps          E           Medium Blue        Red          Orange
  329.  *
  330.  *   One column:
  331.  *   Chip           F           Medium Blue     Medium Blue     Medium Blue
  332.  *   Slow-Fast      F           Medium Blue     Light Blue      Light Blue
  333.  *   Fast           F           Medium Blue     Medium Blue       Green
  334.  *
  335.  *   Two columns:
  336.  *   Chip +SF       F           Medium Blue     Light Blue      Light Blue
  337.  *   Chip +Fast     F           Medium Blue     Medium Blue       Green
  338.  *   SF + Fast      F           Medium Blue     Light Blue        Yellow
  339.  *
  340.  *   Three columns:
  341.  *   C + SF + Fast  F           Medium Blue     Light Blue        Yellow
  342.  *   None           F           Medium Blue     Medium Blue        Red
  343.  *
  344.  *   The source code included with this distribution was compiled with the
  345.  *   Manx Aztec C compiler, version 5.2a in 32-bit integer mode.  Numerous
  346.  *   type casts in the code, as well as other non-alignments with the Lattice
  347.  *   environment would make compilation under versions of Lattice difficult.
  348.  *   Sorry.  Compilation instructions are of course in the makefile included
  349.  *   in the distribution.  Version 2.39 of this program, which is does not
  350.  *   include the ARexx code, can be compiled in 16-bit integer mode on any
  351.  *   version of the Manx Aztec C compiler from 3.6 through current versions.
  352.  *   the files makefile2.39 and makefile2.30 are provided in the version 2.4
  353.  *   distribution for this purpose.
  354.  *
  355.  *   About my part of C code - it wasn't done for speed, as I am sure you can
  356.  *   tell.  If I wanted speed I would have used assembly language.  It also
  357.  *   likely isn't elegant code, by a long shot (unless it's the part I got
  358.  *   from Rokicki's WFrags).  But assembly language is time-consuming to
  359.  *   write, so that won't happen any time soon.  With V2.40 I've done the
  360.  *   promised ARexx port.  I can see that it needs a "Hold", "Cycle", and
  361.  *   "Release" command set to allow better synchronization with other active
  362.  *   processes under debug proceedings.  And perhaps the next version can do
  363.  *   away with the horrors of the fast memory address menu via some proper
  364.  *   utilization of the system mem lists.  Gross comments about the code, or
  365.  *   bug reports may be e-mailed to me at the site domain specified below.
  366.  *   The last release version (2.20) DID have some bugs (two addresses in the
  367.  *   fast mem menu were a factor of a hexadeciment off).  Nobody reported any
  368.  *   of the bugs, but I assume that's because either the program is totally
  369.  *   worthless to any practicing professional and so irritating to everyone
  370.  *   else that they didn't bother with reporting anything, or that since they
  371.  *   had the code they just fixed the bugs or patched the executable and kept
  372.  *   on truckin'.
  373.  *
  374.  *   About everyone else's C code in MM - Let's see, VT100 (Wecker et al) has
  375.  *   been freely distributable since the early days of the Amiga.  When VT100
  376.  *   was first posted, Wecker did not prepend a copyright to the code.  He
  377.  *   later discovered that his employer (DEC) routinely required employees to
  378.  *   sign a contract statement which granted to DEC all rights with respect
  379.  *   to codes written by DEC employees, whether the codes were written on the
  380.  *   company's time/facilities or otherwise.  I do not know how the matter
  381.  *   was resolved, but VT100 still seems to be on the freely distributable
  382.  *   software list.  The menus in MM, while styled with the same code forms
  383.  *   as were used with VT100 v2.3, are of course different in content in any
  384.  *   case.  The WFrags program was, I believe, a version by Tom Rokicki (the
  385.  *   Amiga Tex guy) might be evolved from the Frags program originally put
  386.  *   to the net by Mike Meyer.  WFrags was submitted to the net without a
  387.  *   prepended copyright notice, evidently intended  as freely distributable
  388.  *   software.
  389.  *
  390.  *   The spirit of these contributions is that they are not to be used for
  391.  *   commercial purposes, and the original authors certainly appreciate
  392.  *   being cited for their work.  So I just did that.  The timer codes are
  393.  *   exerpted from a network article by Andy Finkel of CBM, submitted as a
  394.  *   demonstration of the ease of implementing the Amiga timer.device in C.
  395.  *
  396.  *   So, for my part, I add no further restrictions to the codes in MM.
  397.  *   In that spirit, I hereby submit the following Standard Disclaimer:
  398.  *
  399.  *   The authors accept no responsibility for anything either beneficial or
  400.  *   detrimental that may happen as a result of using the codes in MM.  The
  401.  *   codes are intended for non-commercial use only.
  402.  *   
  403.  *
  404.  *   Howard Hull  hull@ncar.ucar.edu
  405.  *
  406.  */
  407.